Location-aware service request handling

ABSTRACT

Example methods and systems are provided for location-aware service request handling. The method may comprise: generating and sending location information associated with virtualized computing instance to a service node or a management entity for transmission to the service node. The location information may identify logical element(s) to which the virtualized computing instance is connected. The method may further comprise: in response to detecting, from the virtualized computing instance, a service request for a service from the service node, generating a modified service request by modifying the service request to include the location information associated with the virtualized computing instance; and sending the modified service request towards the service node.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation application under 35 U.S.C. §120 of U.S. patent application Ser. No. 16/542,304, filed Aug. 16, 2019,which in turn claims the benefit under 35 U.S.C. § 119(a) of PatentCooperation Treaty (PCT) Application No. PCT/CN2019/093374, filed Jun.27, 2019. U.S. patent application Ser. No. 16/542,304 and PCTApplication No. PCT/CN2019/093374 are incorporated herein by reference.

BACKGROUND

Virtualization allows the abstraction and pooling of hardware resourcesto support virtual machines in a software-defined networking (SDN)environment, such as a software-defined data center (SDDC). For example,through server virtualization, virtualization computing instances suchas virtual machines (VMs) running different operating systems may besupported by the same physical machine (e.g., referred to as a “host”).Each VM is generally provisioned with virtual resources to run anoperating system and applications. The virtual resources may includecentral processing unit (CPU) resources, memory resources, storageresources, network resources, etc. In practice, VMs may require variousnetwork services to interact with other entities in the SDN environment.One example is an address assignment service using dynamic hostconfiguration protocol (DHCP) where a VM may request for an InternetProtocol (IP) address assignment. However, such network services may bevulnerable to malicious attacks.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic diagram illustrating an example software-definednetworking (SDN) environment in which location-aware service requesthandling may be performed;

FIG. 2 is a flowchart of an example process for a host to performlocation-aware service request handling in an SDN environment;

FIG. 3 is a flowchart of an example detailed process of location-awareservice request handling in an SDN environment;

FIG. 4 is a schematic diagram illustrating an example configuration tofacilitate location-aware service request handling in an SDNenvironment;

FIG. 5 is a schematic diagram illustrating a first examplelocation-aware service request handling in an SDN environment; and

FIG. 6 is a schematic diagram illustrating a second examplelocation-aware service request handling in an SDN environment.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings, which form a part hereof. In the drawings,similar symbols typically identify similar components, unless contextdictates otherwise. The illustrative embodiments described in thedetailed description, drawings, and claims are not meant to be limiting.Other embodiments may be utilized, and other changes may be made,without departing from the spirit or scope of the subject matterpresented here. It will be readily understood that the aspects of thepresent disclosure, as generally described herein, and illustrated inthe drawings, can be arranged, substituted, combined, and designed in awide variety of different configurations, all of which are explicitlycontemplated herein. Although the terms “first,” “second” and so on areused to describe various elements, these elements should not be limitedby these terms. These terms are used to distinguish one element fromanother. A first element may be referred to as a second element, andvice versa.

Challenges relating to network security will now be explained in moredetail using FIG. 1, which is a schematic diagram illustrating examplesoftware-defined networking (SDN) environment 100 in whichlocation-aware service request handling may be performed. It should beunderstood that, depending on the desired implementation, SDNenvironment 100 may include additional and/or alternative componentsthan that shown in FIG. 1. SDN environment 100 includes multiple hosts,such as host-A 110A, host-B 110B and host-C 110C that areinter-connected via physical network 104. In practice, SDN environment100 may include any number of hosts (also known as a “host computers”,“host devices”, “physical servers”, “server systems”, “transport nodes,”etc.), where each host may be supporting tens or hundreds of VMs.

Each host 110A/110B/110C may include suitable hardware 112A/112B/112Cand virtualization software (e.g., hypervisor-A 114A, hypervisor-B 114B,hypervisor-C 114C) to support various virtual machines (VMs) 131-136.For example, host-A 110A supports VM1 131 and VM4 134; host-B 110Bsupports VMs 132-133; and host-C 110C supports VMs 135-136. Hypervisor114A/114B/114C maintains a mapping between underlying hardware112A/112B/112C and virtual resources allocated to respective VMs131-136. Hardware 112A/112B/112C includes suitable physical components,such as central processing unit(s) (CPU(s)) or processor(s)120A/120B/120C; memory 122A/122B/122C; physical network interfacecontrollers (NICs) 124A/124B/124C; and storage disk(s) 126A/126B/126C,etc.

Virtual resources are allocated to respective VMs 131-136 to support aguest operating system (OS) and application(s). For example, the virtualresources may include virtual CPU, guest physical memory, virtual disk,virtual network interface controller (VNIC), etc. Hardware resources maybe emulated using virtual machine monitors (VMMs). For example in FIG.1, VNICs 141-146 are emulated by corresponding VMMs (not shown forsimplicity). The VMMs may be considered as part of respective VMs131-136, or alternatively, separated from VMs 131-136. Althoughone-to-one relationships are shown, one VM may be associated withmultiple VNICs (each VNIC having its own network address).

Although examples of the present disclosure refer to VMs, it should beunderstood that a “virtual machine” running on a host is merely oneexample of a “virtualized computing instance” or “workload.” Avirtualized computing instance may represent an addressable data computenode (DCN) or isolated user space instance. In practice, any suitabletechnology may be used to provide isolated user space instances, notjust hardware virtualization. Other virtualized computing instances mayinclude containers (e.g., running within a VM or on top of a hostoperating system without the need for a hypervisor or separate operatingsystem or implemented as an operating system level virtualization),virtual private servers, client computers, etc. Such containertechnology is available from, among others, Docker, Inc. The VMs mayalso be complete computational environments, containing virtualequivalents of the hardware and software components of a physicalcomputing system.

The term “hypervisor” may refer generally to a software layer orcomponent that supports the execution of multiple virtualized computinginstances, including system-level software in guest VMs that supportsnamespace containers such as Docker, etc. Hypervisors 114A-C may eachimplement any suitable virtualization technology, such as VMware ESX® orESXi™ (available from VMware, Inc.), Kernel-based Virtual Machine (KVM),etc. The term “packet” may refer generally to a group of bits that canbe transported together, and may be in another form, such as “frame,”“message,” “segment,” etc. The term “traffic” may refer generally tomultiple packets. The term “layer-2” may refer generally to a link layeror Media Access Control (MAC) layer; “layer-3” to a network or InternetProtocol (IP) layer; and “layer-4” to a transport layer (e.g., usingTransmission Control Protocol (TCP), User Datagram Protocol (UDP),etc.), in the Open System Interconnection (OSI) model, although theconcepts described herein may be used with other networking models.

Hypervisor 114A/114B/114C implements virtual switch 115A/115B/115C andlogical distributed router (DR) instance 117A/117B/117C to handle egresspackets from, and ingress packets to, corresponding VMs 131-136. In SDNenvironment 100, logical switches and logical DRs may be implemented ina distributed manner and can span multiple hosts to connect VMs 131-136.For example, logical switches that provide logical layer-2 connectivitymay be implemented collectively by virtual switches 115A-C andrepresented internally using forwarding tables 116A-C at respectivevirtual switches 115A-C. Forwarding tables 116A-C may each includeentries that collectively implement the respective logical switches.Further, logical DRs that provide logical layer-3 connectivity may beimplemented collectively by DR instances 117A-C and representedinternally using routing tables 118A-C at respective DR instances117A-C. Routing tables 118A-C may each include entries that collectivelyimplement the respective logical DRs.

Packets may be received from, or sent to, each VM via an associatedlogical switch port. For example, logical switch ports 151-156 (labelled“LSP1” to “LSP6”) are associated with respective VMs 131-136. Here, theterm “logical port” or “logical switch port” may refer generally to aport on a logical switch to which a virtualized computing instance isconnected. A “logical switch” may refer generally to a software-definednetworking (SDN) construct that is collectively implemented by virtualswitches 115A-C in the example in FIG. 1, whereas a “virtual switch” mayrefer generally to a software switch or software implementation of aphysical switch. In practice, there is usually a one-to-one mappingbetween a logical port on a logical switch and a virtual port on virtualswitch 115A/115B/115C. However, the mapping may change in somescenarios, such as when the logical port is mapped to a differentvirtual port on a different virtual switch after migration of thecorresponding VM (e.g., when the source host and destination host do nothave a distributed virtual switch spanning them).

Through virtualization of networking services in SDN environment 100,logical overlay networks may be provisioned, changed, stored, deletedand restored programmatically without having to reconfigure theunderlying physical hardware architecture. A logical overlay network(also known as “logical network”) may be formed using any suitabletunneling protocol, such as Virtual eXtensible Local Area Network(VXLAN), Stateless Transport Tunneling (STT), Generic NetworkVirtualization Encapsulation (GENEVE), etc. For example, VXLAN is alayer-2 overlay scheme on a layer-3 network that uses tunnelencapsulation to extend layer-2 segments across multiple hosts. In theexample in FIG. 1, VM1 131 on host-A 110A and VM2 132 on host-B 110B maybe connected to the same logical switch and located on the same logicallayer-2 segment, such as a segment with VXLAN network identifier(VNI)=6000.

SDN manager 170 and SDN controller 174 are example network managemententities in SDN environment 100. To send and receive the controlinformation (e.g., configuration information), each host 110A/110B/110Cmay implement local control plane (LCP) agent (not shown) to interactwith SDN controller 174. For example, control-plane channel 101/102/103may be established between SDN controller 174 and host 110A/110B/110Cusing TCP over Secure Sockets Layer (SSL), etc. Management entity170/174 may be implemented using physical machine(s), virtualmachine(s), a combination thereof, etc.

Each host 110A/110B/110C also maintains data-plane connectivity withother host(s) via physical network 104 to facilitate communication amongVMs located on the same logical overlay network. Hypervisor114A/114B/114C may implement a virtual tunnel endpoint (VTEP) toencapsulate and decapsulate packets with an outer header (also known asa tunnel header) identifying a logical overlay network (e.g., VNI=6000).For example in FIG. 1, hypervisor-A 114A implements a first VTEPassociated with (IP address=IP-A, MAC address=MAC-A, VTEP label=VTEP-A),hypervisor-B 114B implements a second VTEP with (IP-B, MAC-B, VTEP-B)and hypervisor-C 114C implements a third VTEP with (IP-C, MAC-C,VTEP-C). Encapsulated packets may be sent via a tunnel establishedbetween a pair of VTEPs over physical network 104, over which respectivehosts are in layer-3 connectivity with one another.

In the example in FIG. 1, service node 161/162 may be configured toprovide service(s) to VMs 131-134. For example, service node 161supported by host-C 110C may be configured to provide a hostconfiguration service using dynamic host configuration protocol (DHCP),such as to assign an IP address to VM1 131. DHCP may also be used toassign other configuration parameters, such as a subnet mask, a defaultgateway, a Domain Name Service (DNS) server address, etc. Depending onthe desired implementation, service node 161 may be an edge node orlogical service router (SR), which represents a centralized routingcomponent that is deployed to provide centralized stateful services,such as DHCP, load balancing, network address translation (NAT), etc. Itshould be understood that service node 161 may be implemented using oneVM (as shown in FIG. 1) or multiple VMs, or a physical machine (e.g.,bare metal server).

Conventionally, service node 161/162 is susceptible to malicious attacksthat are harmful to network security. For example, a spoofing attackoccurs when a malicious party impersonates another entity on the networkin order to launch attacks against particular servers, spread malware,bypass access controls, steal information, etc. One example is MACaddress spoofing where a malicious party uses a spoofed source MACaddress (e.g., impersonating VM1 131) to launch a DHCP starvation attackagainst a DHCP server. During the attack, malicious VMs may flood anorganization's DHCP server(s) with DHCP request messages using spoofedsource MAC addresses, which affects network performance.

Location-Aware Service Request Handling

According to examples of the present disclosure, a “location-aware”approach may be implemented to improve network security in SDNenvironment 100. In more detail, FIG. 2 is a flowchart of exampleprocess 200 for host 110A/110B to perform location-aware service requesthandling in SDN environment 100. Example process 200 may include one ormore operations, functions, or actions illustrated by one or moreblocks, such as 210 to 240. The various blocks may be combined intofewer blocks, divided into additional blocks, and/or eliminateddepending on the desired implementation. In practice, example process200 may be implemented by any host 110A/110B, such as using virtualswitch 115A/115B (e.g., relay agent 119A/119B) implemented by hypervisor114A/114B. In the following, various examples will be discussed using VM131/132/133/134 as an example “virtualized computing instance,” host110A/110B as an example “host.”

At 210 in FIG. 2, host-A 110A may generate and send location information(see 181-182 in FIG. 1) associated with VM1 131 to service node 161, ormanagement entity 170/174 for transmission to service node 161. Thelocation information associated with VM1 131 may identify one or morelogical elements to which VM1 131 is connected. As used herein, the term“logical element” may refer generally to a logical entity that isdeployed in a logical network, such as a logical switch port, logicalswitch, logical router port, logical router, VNIC, etc. The term“location information” may identify any suitable logical element(s) thatindicate a unique location associated with the VM within the logicalnetwork. The location information may be in any suitable format, such asID, address, etc.

At 220, 230 and 240 in FIG. 2, in response to detecting, from VM1 131, aservice request (see 191 in FIG. 1) to request for a service fromservice node 161, host-A 110A may generate and send a modified servicerequest (see 192 in FIG. 1). The “modified service request” may begenerated by modifying the service request to include locationinformation associated with VM1 131. For example, the locationinformation may identify a logical switch port (e.g., LSP1 151) and alogical switch (e.g., LS1 401 in FIG. 4) to which VM1 131 is connected.This way, the modified service request may be sent to service node 161to cause service node 161 to perform verification based on the locationinformation when providing the service to VM1 131.

As used herein, the term “service” may be any suitable functionalityprovided by service node 161, such as IP address assignment according toDHCP, parameter configuration, domain name system (DNS) service, etc. Inthe case of DHCP, the “service request” may be a DHCP request to requestfor an IP address assignment from “service node”=DHCP server 161. Toimplement the example in FIG. 2, a service node may be configured toenable a location-aware service request handling functionality, such asrelay agent information option in the case of DHCP. In this case, theservice request may be modified to enable the relay agent informationoption by configuring a circuit ID sub-option field to identify LSP1 151(“first logical element”) and a remote ID sub-option field to identifyLS1 401 (“second logical element”) that are connected to VM1 131.Various examples will be discussed below using FIGS. 3-6.

Configuration

FIG. 3 is a flowchart of example detailed process 300 for location-awareservice request handling in SDN environment 100. Example process 300 mayinclude one or more operations, functions, or actions illustrated at 305to 390. The various operations, functions or actions may be combinedinto fewer blocks, divided into additional blocks, and/or eliminateddepending on the desired implementation. Example process 300 may beimplemented by any suitable management entity (e.g., SDN manager 170and/or SDN controller 174) and host 110A/110B (e.g., using relay agent119A/119B implemented by hypervisor 114A/114B), etc.

The example in FIG. 3 will be explained using FIG. 4, which is aschematic diagram illustrating first example location-aware servicerequest handling 400 in SDN environment 100. In the example in FIG. 4,VM1 131, VM2 132 and DHCP server 161 are connected to logical switch LS1401 associated with a first subnet (e.g., 10.10.10.0/24). VM3 133 andVM4 134 are connected to logical switch LS2 402 (e.g., 20.20.20.0/24).DHCP server 161 is accessible by VM3 133 and VM4 134 via logical routerDR 403.

(a) Location Information

At 305 and 310 in FIG. 3, in response to detecting that a VNIC of a VMattaches to a logical switch, host 110A/110B may create a logical switchport for the VNIC and bind the VNIC to the logical switch port. Forexample in FIG. 4, VNIC1 141 of VM1 131 and VNIC2 142 of VM2 132 mayattach to first logical switch=LS1 401. Further, VNIC3 143 of VM3 133and VNIC4 144 of VM4 134 may attach to second logical switch=LS2 402. Inthis case, at host-A 110A, when VNIC1 141 of VM1 131 attaches to LS1401, virtual switch 115A may create and bind LSP1 151 to VNIC1 141. WhenVNIC4 144 of VM4 134 attaches to LS2 402, virtual switch 115A may createand bind LSP4 154 to VNIC4 144. Similarly, at host-B 110B, virtualswitch 115B may create and bind LSP1 152 to VNIC2 142, as well as LSP3153 to VNIC3 143.

At 315 in FIG. 3, host 110A/110B may generate and send locationinformation associated with each VM to SDN manager 170 for transmissionto DHCP server 161. In the example in FIG. 4, host-A 110A may send SDNmanager 170 location information (see 410) associated with VM1 131 andVM4 134. The location information identifies logical element(s) to whicheach VM is connected, such as (LSP1, LS1) for VM1 131 and (LSP4, LS2)for VM4 134. Further, host-B 110B may send SDN manager 170 locationinformation (see 420) identifying (LSP2, LS1) for VM2 132 and (LSP3,LS2) for VM3 133.

In practice, it should be understood that location information 410/420may be sent to DHCP server 161 directly, or via another intermediateentity. The location information 410/420 is uniquely associated witheach VM. For example in FIG. 4, location information=(LSP1, LS1) isuniquely associated with VM1 131 because only VM1 131 is connected toboth LSP1 151 and LS1 401. Similarly, location information=(LSP2, LS2)is uniquely associated with VM2 132 because only VM2 132 is connected toboth LSP2 152 and LS2 402.

(b) Policy Information

At 320 in FIG. 3, SDN manager 170 may generate location-policy mappinginformation (see 440 in FIG. 4) by storing location information (see410-420) in association with policy information (see 430) configured foreach VM. Here, the term “policy information” may refer generally to anysuitable rule(s) or requirement(s) associated with a service. Inpractice, the policy information may be configured by a user (e.g.,network administrator) operating user device 404 via any suitableinterface supported by SDN manager 170, such as graphical user interface(GUI), command-line interface (CLI), application programming interface(API) calls, etc.

In the case of service=DHCP, the policy information may specify how IPaddresses are assigned, such as dhcpPolicy=POOL (allocation from a poolof IP addresses), dhcpPolicy=FIXED (fixed IP address allocation), etc.For example, VM1 131 is associated with location information=(LSP1, LS1)and DHCP policy information dhcpPolicy=POOL. Further, VM2 132 isassociated with (LSP2, LS1, dhcpPolicy=POOL), VM3 133 with (LSP3, LS2,dhcpPolicy=POOL), and VM4 134 with (LSP4, LS2, dhcpPolicy=FIXED). See441-444 in FIG. 4.

At 325 and 330 in FIG. 3, SDN manager 170 may send location-policymapping information 440 to service node=DHCP server 161 via SDNcontroller 174. This has the effect of synchronizing the DHCP policyinformation with SDN controller 174 on the central control plane. Anexample will be described using FIG. 5, which is a schematic diagramillustrating first example 500 of location-aware request handling in SDNenvironment 100. Referring to 510 in FIG. 5, SDN manager 170 may sendthe following location-policy mapping information to DHCP server 161 viaSDN controller 174: (LSP1, LS1, policy=POOL) associated with VM1 131 and(LSP4, LS2, policy=FIXED) associated with VM4 134.

(c) Enabling Location-Aware Functionality

At 335 and 340 in FIG. 3, SDN manager 170 may configure DHCP server 161to enable location-aware DHCP request handling. This way, DHCP server161 may use the location information as a form of verification orauthentication during DHCP request handling before applying associatedpolicy information for a particular VM. Note that configuration 520 ofDHCP server 161 may be performed before, during or after sending thelocation-policy mapping information.

In the case of DHCP, block 340 may involve SDN manager 170 configuringDHCP server 161 to enable a DHCP relay agent information option (alsoknown as “option 82,” see 520 in FIG. 5). The DHCP relay agentinformation option is defined in request for comments (RFC) 3046published by a network working group of The Internet Society (2001). Therelay agent information option may be enabled to allow virtual switch115A/115B (or more particularly relay agent 119A/119B) to conveylocation information associated with a particular DHCP client. Theoption may include any suitable sub-option, such as a “circuit ID”sub-option and a “remote ID” sub-option.

Conventionally, the circuit ID may be used to convey an agent-local IDof an incoming circuit, and the remote ID a trusted ID for a remotehigh-speed modem. According to examples of the present disclosure, DHCPrelay agent information sub-option(s) may be used to convey locationinformation using (circuit ID=logical switch port ID, remote ID=logicalswitch ID). Note that sub-option fields may be configured differently(e.g., circuit ID=logical switch ID, remote ID=logical switch port ID),provided they specify the necessary location information associated witha DHCP client. Additionally or alternatively, a sub-option field mayspecify an ID associated with another logical element (e.g., VNIC)connected to VM.

Location-Aware DHCP Request Handling

DHCP operations generally fall into four phases: (1) a DHCP clientperforming DHCP server discovery by sending a DHCP Discover message; (2)DHCP server 161 performing IP lease offer by sending a DHCP Offermessage; (3) the DHCP client accepting the offer by sending a DHCPRequest message; and (4) DHCP server 161 returns a DHCP Acknowledgement(ACK) or Negative Acknowledgement (NACK) message to the DHCP client. TheDHCP Discover, DHCP Offer, DHCP Request and DHCP ACK/NACK messagesgenerally have the same message format. An operation (OP) code may beused to specify the message type, such as code=1 for a request from theDHCP client and code=2 for a reply from DHCP server 161.

In the following, consider a scenario where DHCP client=VM1 131 requiresan IP address assignment from DHCP server 161. Assume that VM1 131 hasreceived a DHCP Offer message from DHCP server 161, which is alsoattached to LS1 401. To request for IP address assignment, VM1 131 maygenerate and send a DHCP request message (see “01” 530 in FIG. 5)specifying source address information (source IP address=0.0.0.0, MACaddress=MAC-VM1). Depending on the desired implementation, DHCP request530 may be a broadcast message to accept a DHCP offer from DHCP server161 (and reject any other offer). In this case, DHCP request 530 mayspecify destination address information (IP address=255.255.255.255, MACaddress=FF:FF:FF:FF:FF:FF).

At 345 and 350 in FIG. 3, virtual switch 115A (e.g., using relay agent119A) may perform snooping to detect or intercept DHCP request 530 fromVM1 131 via LSP1 151 and VNIC1 141, and insert location informationassociated with VM1 131. In particular, block 350 may involve generatinga modified DHCP request (see “Q2” 540 in FIG. 5) to enable the relayagent information option by configuring sub-option fields (circuitID=LSP1, remote ID=LS1) to indicate a unique location of VM1 131.

At 355 in FIG. 3, modified DHCP request 540 is broadcasted to reach DHCPserver 161 (and other DHCP servers that are not shown). To reach host-C110C, for example, modified DHCP request 540 may be encapsulated with anouter header (e.g., GENEVE header) identifying (a) a source VTEP (e.g.,VTEP IP address=IP-A, MAC address=MAC-A) implemented by hypervisor-A114A on host-A 110A and (b) a destination VTEP (e.g., VTEP IPaddress=IP-C, MAC address=MAC-C) implemented by hypervisor-C 110C onhost-C 110C. Since VM1 131 and VM2 132 are attached to the same LS1 401in the example in FIG. 4, modified DHCP request 540 is also sent tohost-B 110B, where it will be dropped.

At 360 and 365 in FIG. 3, in response to detecting modified DHCP request540, DHCP server 161 may perform verification as to whether (circuitID=LSP1, remote ID=LS1) in modified DHCP request 540 match with locationinformation 510/440 received from SDN manager 170. This may involvesearching for (LSP1, LS1) in location information 510/440. If found, theprocess proceeds to block 370. Otherwise (not found), modified DHCPrequest 540 will be dropped because the location information cannot beverified.

At 370 and 375 in FIG. 3, in response to finding a match (see 550 inFIG. 5), DHCP server 161 may apply dhcpPolicy=POOL associated with(LSP1, LS1), and respond with a DHCP reply (see “R1” 560). In theexample in FIG. 5, DHCP server 161 assigns an IP address=IP-1 to VM1 131from a pool of multiple IP addresses. DHCP reply 560 may be a unicastDHCP ACK message specifying source address information (IP address=IP-D,MAC address=MAC-D) associated with DHCP server 161. DHCP reply 560 alsoincludes a “your IP address” (YIADDR) field specifying IP address=IP-VM1assigned by DHCP server 161 to VM1 131.

At 380 in FIG. 3, virtual switch 115A (e.g., using relay agent 119A) mayperform snooping to detect or intercept DHCP reply 560 from DHCP server161. Depending on the desired implementation, DHCP reply 560 may or maynot specify sub-option fields (circuit ID=LSP1, remote ID=LS1)associated with VM1 131. If yes, (circuit ID=LSP1, remote ID=LS1) may beremoved from DHCP reply 560 before it is forwarded to VM1 131. This way,location-aware service request handling may be performed in a mannerthat is transparent to VM1 131. See corresponding 385-390 in FIG. 3. VM1131 may receive (modified) DHCP reply 570 via LSP1 151 and VNIC1 141,and start using IP address=IP-1 for its communication with otherentities.

Examples of the present disclosure should be contrasted againstapproaches that require a network administrator to bind a DHCP client'sMAC address to a particular DHCP policy configured for the DHCP client.Such approaches may be vulnerable to malicious attacks because MACaddresses (e.g., MAC-1 of VM1 131) may be spoofed. Further, a DHCPclient's MAC address might change during the lifecycle of the VM, whichnecessitates an update to the relevant (MAC address, policy) mapping.

In contrast, using a “location-aware” approach, the location information(e.g., LSP1, LS1) may represent a more permanent identity of VM1 131.Since the location information is managed and distributed by SDN manager170 and SDN controller 174 (instead of the VMs themselves), networksecurity may be improved. Since MAC address may be easily spoofed, thelocation-aware approach also decouples a VM's MAC address from the IPaddress assignment process using DHCP. To further enhance networksecurity, the location information may be maintained by networkmanagement entity 170/174 and independently from each VM.

The location-aware approach may also be self-adaptive. For example, whenVM1 131 is migrated from host-A 110A to host-B 110B, VM1 131 usuallyremains attached to LSP1 151 and LS1 401. In this case, it is notnecessary to update associated location-policy mappinginformation=(LSP1, LS1, dhcpPolicy=POOL) stored by SDN manager 170 andDHCP server 161. However, when VNIC1 141 detaches from LS1 401, or VNIC1141 is destroyed, host-A 110A may report the detach or destroy event toSDN manager 170 such that the associated location-policy mappinginformation may be removed. In this case, DHCP server 161 may reclaimthe IP address (e.g., IP-1) assigned to VM1 131, and reassign it toanother endpoint.

Other Services

Besides DHCP, it should be understood that examples of the presentdisclosure may be implemented using any additional and/or alternative“service.” FIG. 6 is schematic diagram illustrating second example 600of location-aware request handling in SDN environment 100. In thisexample, service node 162 may be configured to provide any suitable(non-DHCP) service, such as resource allocation service, domain nametranslation service using domain name system (DNS), etc.

At 610 in FIG. 6, SDN manager 170 may disseminate location-policymapping information associated with a service provided by service node162 via SDN controller 174. For example, VM1 131 is associated withlocation information (LSP1, LS1) and policy information (policy=P1); VM2132 with (LSP2, LS1, P2); VM3 133 with (LSP3, LS2, P3); and VM4 134 with(LSP4, LS2, P4). See 611-614 in FIG. 6. Similar to the example in FIG.4, service policies P1-P4 may be configured by a user (e.g., networkadministrator) operating user device 404 via a user interface supportedby SDN manager 170. At 620, SDN manager 170 may also configure servicenode 162 to enable a location-aware service request handlingfunctionality. This enables service node 161 to perform verificationbased on the location information.

At 630 and 640 in FIG. 6, in response to detecting a service request(see “Q3” 630) from VM3 133 via VNIC3 143 and LSP3 153, relay agent 119Bat virtual switch 115B may generate and send a modified service request(see “Q4” 640) in a unicast manner. Modified service request 640includes location information (LSP3, LS2) identifying LSP3 153 and LS2401 to which VNIC3 143 of VM3 133 attaches (see FIG. 4). Modifiedservice request 640 also specifies source address information (IP-3,MAC-3) associated with VM3 133, and destination address information(IP-S, MAC-S) associated with service node 162.

At 650 in FIG. 6, in response to verifying that (LSP3, LS2) in modifiedservice request 640 matches with location information 613 received fromSDN manager 170, service node 162 may apply policy=P3 configured for VM3133. At 660, service node 162 responds to modified service request 640with a service reply (see “R3” 660). For example, service reply 660 mayidentify a resource allocated to VM3 133, or information required by VM3133. Service reply 660 also specifies source address information (IP-S,MAC-S) associated with service node 162, and destination addressinformation (IP-3, MAC-3) associated with VM3 133.

At 670 and 680 in FIG. 6, virtual switch 1158 may receive and forwardservice reply 660 to VM3 133. As explained using FIG. 5, locationinformation (LSP3, LS2) may be first removed before forwarding modifiedservice reply 670 to VM3 133.

In the case of DNS, a DNS policy configured for a particular VM mayinclude a list of domain names that will be translated for the VM. UsingVM1 131 as an example, DNS policy=P1 (see 611) associated with (LSP1,LS1) may specify a whitelist of translatable domain names, such as(www.domain-1a.com, www.domain-1b.com, www.domain-1c.com). In anotherexample, DNS policy=P3 (see 613) associated with (LSP3, LS1) may specifyanother whitelist of translatable domain names, such as(www.domain-1a.com, www.domain-3a.com, www.domain-3b.com) for VM3 133.Alternatively or additionally, each DNS policy may specify a blacklistof domain names that will blocked (i.e., not translated) for aparticular VM.

Service node 162 in FIG. 6 may be a DNS server that is configured toperform verification based on the location information in modified DNSrequest 640 prior to applying a DNS policy associated with the locationinformation. In practice, location information (LSP3, LS2) may be addedto any suitable existing or newly configured field(s) in modified DNSrequest 640. Since service node 162 is configured to verify the locationinformation added to DNS requests before responding with a DNS reply,the risk of malicious attacks may be reduced. One example is DNS serverspoofing where a malicious party alters DNS records that are used todirect traffic to fraudulent websites.

Container Implementation

Although explained using VMs 131-134, it should be understood that SDNenvironment 100 may include other virtual workloads, such as containers,etc. As used herein, the term “container” (also known as “containerinstance”) is used generally to describe an application that isencapsulated with all its dependencies (e.g., binaries, libraries,etc.). In the examples in FIG. 1 to FIG. 6, container technologies maybe used to run various containers inside respective VMs 131-134.Containers are “OS-less”, meaning that they do not include any OS thatcould weigh 10s of Gigabytes (GB). This makes containers morelightweight, portable, efficient and suitable for delivery into anisolated OS environment. Running containers inside a VM (known as“containers-on-virtual-machine” approach) not only leverages thebenefits of container technologies but also that of virtualizationtechnologies. The containers may be executed as isolated processesinside respective VMs.

Computer System

The above examples can be implemented by hardware (including hardwarelogic circuitry), software or firmware or a combination thereof. Theabove examples may be implemented by any suitable computing device,computer system, etc. The computer system may include processor(s),memory unit(s) and physical NIC(s) that may communicate with each othervia a communication bus, etc. The computer system may include anon-transitory computer-readable medium having stored thereoninstructions or program code that, when executed by the processor, causethe processor to perform process(es) described herein with reference toFIG. 1 to FIG. 6. For example, the instructions or program code, whenexecuted by the processor of the computer system, may cause theprocessor to perform location-aware service request handling accordingto examples of the present disclosure.

The techniques introduced above can be implemented in special-purposehardwired circuitry, in software and/or firmware in conjunction withprogrammable circuitry, or in a combination thereof. Special-purposehardwired circuitry may be in the form of, for example, one or moreapplication-specific integrated circuits (ASICs), programmable logicdevices (PLDs), field-programmable gate arrays (FPGAs), and others. Theterm ‘processor’ is to be interpreted broadly to include a processingunit, ASIC, logic unit, or programmable gate array etc.

The foregoing detailed description has set forth various embodiments ofthe devices and/or processes via the use of block diagrams, flowcharts,and/or examples. Insofar as such block diagrams, flowcharts, and/orexamples contain one or more functions and/or operations, it will beunderstood by those within the art that each function and/or operationwithin such block diagrams, flowcharts, or examples can be implemented,individually and/or collectively, by a wide range of hardware, software,firmware, or any combination thereof.

Those skilled in the art will recognize that some aspects of theembodiments disclosed herein, in whole or in part, can be equivalentlyimplemented in integrated circuits, as one or more computer programsrunning on one or more computers (e.g., as one or more programs runningon one or more computing systems), as one or more programs running onone or more processors (e.g., as one or more programs running on one ormore microprocessors), as firmware, or as virtually any combinationthereof, and that designing the circuitry and/or writing the code forthe software and or firmware would be well within the skill of one ofskill in the art in light of this disclosure.

Software and/or other instructions to implement the techniquesintroduced here may be stored on a non-transitory computer-readablestorage medium and may be executed by one or more general-purpose orspecial-purpose programmable microprocessors. A “computer-readablestorage medium”, as the term is used herein, includes any mechanism thatprovides (i.e., stores and/or transmits) information in a formaccessible by a machine (e.g., a computer, network device, personaldigital assistant (PDA), mobile device, manufacturing tool, any devicewith a set of one or more processors, etc.). A computer-readable storagemedium may include recordable/non recordable media (e.g., read-onlymemory (ROM), random access memory (RAM), magnetic disk or opticalstorage media, flash memory devices, etc.).

The drawings are only illustrations of an example, wherein the units orprocedure shown in the drawings are not necessarily essential forimplementing the present disclosure. Those skilled in the art willunderstand that the units in the device in the examples can be arrangedin the device in the examples as described, or can be alternativelylocated in one or more devices different from that in the examples. Theunits in the examples described can be combined into one module orfurther divided into a plurality of sub-units.

We claim:
 1. A method for a service node to perform verification ofservice requests in a software-defined networking (SDN) environment, themethod comprising: receiving, by the service node, first locationinformation associated with a virtualized computing instance, whereinthe first location information uniquely identifies one or more logicalelements to which the virtualized computing instance is connected;storing, by the service node, the first location information; detecting,by the service node, a service request that indicates the virtualizedcomputing instance as a source of the request and that includes secondlocation information; determining, by the service node, whether thesecond location information in the service request matches the storedfirst location information; and verifying, by the service node,authenticity of the service request, in response to determination thatthe second location information matches the stored first locationinformation.
 2. The method of claim 1, further comprising: dropping, bythe service node, the service request, in response to a failure toverify the authenticity of the service request due to a mismatch betweenthe second location information and the stored first locationinformation.
 3. The method of claim 1, wherein the service nodecomprises a dynamic host configuration protocol (DHCP) server, andwherein the service request comprises a DHCP request.
 4. The method ofclaim 1, wherein the service node comprises a domain name system (DNS)server, and wherein the service request comprises a DNS request.
 5. Themethod of claim 1, further comprising: in response to verifying theauthenticity of the service request due to the second locationinformation matching the stored first location information, applying, bythe service node, a policy associated with the second locationinformation to identify an address; and sending, by the service node,the identified address in a reply to the service request.
 6. The methodof claim 1, wherein the second location information identifies a logicalswitch port and a logical switch to which the virtualized computinginstance is connected, and wherein the service request detected by theservice node is a modified service request that results from insertionof the second location information into an original service request sentby the virtualized computing instance.
 7. The method of claim 1, whereinfor security, the first location information is managed and distributedby a network manager instead of the virtualized computing instance, andwherein receiving the first location information includes, receiving, bythe service node, the first location information from the networkmanager.
 8. A non-transitory computer-readable storage medium thatincludes a set of instructions which, in response to execution by aprocessor of a service node, cause the processor to perform verificationof service requests in a software-defined networking (SDN) environment,wherein the method comprises: receiving, by the service node, firstlocation information associated with a virtualized computing instance,wherein the first location information uniquely identifies one or morelogical elements to which the virtualized computing instance isconnected; storing, by the service node, the first location information;detecting, by the service node, a service request that indicates thevirtualized computing instance as a source of the request and thatincludes second location information; determining, by the service node,whether the second location information in the service request matchesthe stored first location information; and verifying, by the servicenode, authenticity of the service request, in response to determinationthat the second location information matches the stored first locationinformation.
 9. The non-transitory computer-readable storage medium ofclaim 8, wherein the method further comprises: dropping, by the servicenode, the service request, in response to a failure to verify theauthenticity of the service request due to a mismatch between the secondlocation information and the stored first location information.
 10. Thenon-transitory computer-readable storage medium of claim 8, wherein theservice node comprises a dynamic host configuration protocol (DHCP)server, and wherein the service request comprises a DHCP request. 11.The non-transitory computer-readable storage medium of claim 8, whereinthe service node comprises a domain name system (DNS) server, andwherein the service request comprises a DNS request.
 12. Thenon-transitory computer-readable storage medium of claim 8, wherein themethod further comprises: in response to verifying the authenticity ofthe service request due to the second location information matching thestored first location information, applying, by the service node, apolicy associated with the second location information to identify anaddress; and sending, by the service node, the identified address in areply to the service request.
 13. The non-transitory computer-readablestorage medium of claim 8, wherein the second location informationidentifies a logical switch port and a logical switch to which thevirtualized computing instance is connected, and wherein the servicerequest detected by the service node is a modified service request thatresults from insertion of the second location information into anoriginal service request sent by the virtualized computing instance. 14.The non-transitory computer-readable storage medium of claim 8, whereinfor security, the first location information is managed and distributedby a network manager instead of the virtualized computing instance, andwherein receiving the first location information includes, receiving, bythe service node, the first location information from the networkmanager.
 15. A service node, comprising: one or more processors; and anon-transitory computer-readable storage medium that includes a set ofinstructions which, in response to execution by the one or moreprocessors, cause the one or more processors to perform operations toverify service requests in a software-defined networking (SDN)environment, wherein the operations include: receive first locationinformation associated with a virtualized computing instance, whereinthe first location information uniquely identifies one or more logicalelements to which the virtualized computing instance is connected; storethe first location information; detect a service request that indicatesthe virtualized computing instance as a source of the request and thatincludes second location information; determine whether the secondlocation information in the service request matches the stored firstlocation information; and verify authenticity of the service request, inresponse to determination that the second location information matchesthe stored first location information.
 16. The service node of claim 15,wherein the instructions further include: drop the service request, inresponse to a failure to verify the authenticity of the service requestdue to a mismatch between the second location information and the storedfirst location information.
 17. The service node of claim 15, whereinthe service node comprises a dynamic host configuration protocol (DHCP)server, and wherein the service request comprises a DHCP request. 18.The service node of claim 15, wherein the service node comprises adomain name system (DNS) server, and wherein the service requestcomprises a DNS request.
 19. The service node of claim 15, wherein theinstructions further include: in response to verification of theauthenticity of the service request due to the second locationinformation being matched with the stored first location information,apply a policy associated with the second location information toidentify an address; and send the identified address in a reply to theservice request.
 20. The service node of claim 15, wherein the secondlocation information identifies a logical switch port and a logicalswitch to which the virtualized computing instance is connected, andwherein the service request detected by the service node is a modifiedservice request that results from insertion of the second locationinformation into an original service request sent by the virtualizedcomputing instance.
 21. The service node of claim 15, wherein forsecurity, the first location information is managed and distributed by anetwork manager instead of the virtualized computing instance, andwherein the service node is configured to receive the first locationinformation from the network manager.